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Of late Multitenant model with In-Memory database has become prominent 
area for research. The paper has used advantages of multitenancy to reduce the 
cost for hardware, labor and make availability of storage by sharing database 
memory and file execution. The purpose of this paper is to give overview of 
proposed Supple architecture for implementing in-memory database backend 
and multitenancy, applicable in public and private cloud settings. Backend in- 
memory database uses column-oriented approach with dictionary based 
compression technique. We used dedicated sample benchmark for the 
workload processing and also adopt the SLA penalty model. In particular, we 
present two approximation algorithms, multi-tenant placement (MTP) and 
best-fit greedy to show the quality of tenant placement. The experimental 
results show that MTP algorithm is scalable and efficient in comparison with 
best-fit greedy algorithm over proposed architecture. 
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1. INTRODUCTION 

Conventionally, in-memory databases have been in use for applications which were performance 
sensitive such as financial services markets. In-memory database claim to provide an alternative to the OLAP. 
Instead of pulling the data from a disk, keeping it in memory (RAM) speeds up the processing and response 
time of data by order of magnitude. This is the reason why in-memory Database is booming in industry these 
days. With the expeditious increase of software-as-a-service (SaaS), it has become important to operate 
services at a faster response time for SaaS providers. With the aim of to reduce operational cost, multi-tenancy 
provides methods for combining multiple tenants of hosted application into the same system. Multi tenancy 
can be employed in the database layer in such a way that a single database can be used by multiple customers 
i.e. tenants. A cloud uses technology of multitenancy to share IT resources among multiple applications and 
tenants securely. Virtualization-based architectures is used by some clouds to isolate tenants and some uses 
custom software architectures to get the job done. In this paper we have shown the proposed architecture for 
standing tenant placement for query request with sample HR benchmark design combined both approaches in 
memory and multitenancy. To improve sever utilization and resource profit, tested two algorithm(s) (1) best 
fit greedy (2) MTP. In Supple architecture it consists mainly three components (1) Cluster head: maintain 
placement information over in-memory database. (2) Router: based on cluster map it forwards query request 
to the suitable instance manager and (3) Instance Manager: distribution of requests across the tenant user. The 
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supple architecture adopt microsoft azure platform and also provide physical machine that turned into virtual 
disk pool. 


2. IN-MEMORY DATABASE 

Earlier in-memory databases have been used in the performance sensitive applications which were 
performance sensitive like financial services markets. However now a days in-memory databases have become 
more generally adopted. At the same time, the SaaS model has become popular and customers are gaining 
interest in this model, as it decreases their the burden of the hassle of operating the system, which requires 
provisioning the hardware as well as maintaining, operating and configuring application servers and databases. 
The key difference between in-memory database (IMDB) and disk resident database (DRDB) is that data in 
IMDB resides in main memory permanently and in DRDB, data resides permanently on disk. Since the chip 
density is increasing day by day and semiconductor memory is becoming cheaper so it’s possible to store huge 
amount of data in memory [1]. IMDBs can provide performance by an order of magnitude faster as compared 
to DRDBs. In-memory which is one of the memory resident systems and compares its processing time with a 
typical disc resident database. Of course the IMDB gave better performance and response time. Complexity in 
IMDBs is reduced as the number of machine instructions reduced, buffer pool management is not required, 
and no need of extra data copies, index pages decreases, and their simplified structure is possible. As a 
consequence the design becomes simple and more concise, and requests are performed faster. IMDSs have also 
lower memory and CPU requirements. Also the design and arrangement of data on disk is much more 
unfavorable than arrangement of data on main memory. Real time applications require fast response. So IMDBs 
play crucial role for real time applications. “Can entire database fit into main memory?” The answer depends 
on the application. If size of application is limited and is growing at slower pace than it is possible to have 
entire database in main memory. For example database employee details of some small company. But for real 
time applications it is must that data reside in main memory. If size of database is too large to fit into the main 
memory for example an application with satellite image data the data can be categorized as hot and cold data. 
The data which is frequently required is categorized as hot and data which is rarely required and is voluminous 
is cold data. The hot data lay in in-main memory and cold is stored on disk. 


2.1. Challenges with in-memory systems 

In-memory is liable to change rapidly while disk storage is nonvolatile. So regular backups must be 
taken (on disk) and at the same time it is to be taken care that performance of IMDB is not affected. If disk fail, 
data on other disks can be secured and recovery from disk is easy but if memory fails, entire database is lost. 
The performance gain of IMDB can be limited by the application operating it, layout and implementation of 
database itself, the hardware on which the database is running and the association with external devices. Large 
volumes of data with lower frequency reads are not much more efficient with IMDBs. Many papers have 
discussed the impact of memory residency of some important functional components of database management 
system (DBMS) like concurrency control, access methods, commit processing, query processing and 
performance etc. Many papers have discussed the issues related to IMDB recovery and briefly examine some 
of the solutions [2]. 


2.2. In-memory architecture 

To understand the architecture of in-memory, architecture of oracle database is considered here, which 
is categorized under the in-memory cache architecture. The elements of architecture include database 
processes, memory-resident data structures, shared libraries and administrative programs. Indexes, system 
tables, tables, cursors, locks, temporary indexes and compiled commands together make up the memory 
resident data structures. Through direct link and client/server connections, the application can be linked to the 
database or IMDB cache. Information is received by replication agents from master databases and is sent to 
subscriber databases. Asynchronous data transfers between oracle database and cache groups in the in-memory 
database cache are performed by cache agent. Figurel shows oracle’s in-memory database cache architecture 
[3]. External memory is accessed only in three cases: 
— To load copy of main memory during system startup. 
— Checkpoint over writing, recovery and on Logging. 
— To persists data about data and configuration changes. 
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Figure 1. In-memory database cache architecture 


So for these type of tasks IMDBs rely on paged data handling while all other operations run purely on 
main memory. The database community is going to experience a great shift in market in the coming years as 
in-memory databases are becoming more effective and affordable. Although in-memory database mainly 
consists two storage approach namely row-oriented (database re-structuring) and column-oriented. Many 
databases can use both approaches row-oriented as well as column-oriented. 


2.3. Multitenancy 

With the aim of reducing operational cost, multi-tenancy provides methods for combining multiple 
customers (i.e. tenants) of deployed application which run on the same infrastructure. Database layer can be 
employed in the Multi tenancy architecture can be utilized in the database layer in such a way that a single 
database can be shared by multiple customer. A cloud uses technology of multitenancy to share IT resources 
among multiple applications and tenants securely. Virtualization-based architectures is used by some clouds to 
isolate tenants and some uses custom software architectures to get the job done. Depending on requirements of 
customer such as security, high availability, customizability, the choice of appropriate tenancy model is 
decided. There are several possible multi-tenant schemes like shared design, VM based design etc. For tenant 
applications are a well-known example of a type of application whose data and workloads can be partitioned 
easily. For instance, with tenant applications, data and workload can typically be partitioned along tenant 
boundaries since most requests are within the confines of a tenant. So, by considering a framework which takes 
the tenant workloads as input, their performance service level objectives (SLOs), and the server hardware 
which is obtainable to the SaaS provider. 


3. ASUPPLE INFRASTRUCTURE FOR MULTITENANCY OVER IN-MEMORY DATABASE 
Proposed architecture for multitenancy using in-memory is shown in Figure 2 which consists major 
three components. 


3.1. Component(s) 
3.1.1. Cluster head 

There is single cluster leader exists in a supple infrastructure and it assigns one or more tenant to 
server. Each tenant's replica is assigned to the individual instance handler, so that each instance handler must 
process different data from multiple tenants. The cluster head maintains the placement information over in 
memory database performance with hard disk based shown in Figure 2, which it propagates to the route. In 
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addition the cluster head also observe active nodes, starts and stops severs, placement assessment and migration 
of tenant between servers. Request processing cannot assessed directly by the cluster head. The cluster head 
process has to run on all active severs to handle single point of failure to make highly availability that can be 
possible by running a cluster head process on all active servers. 


3.1.2. Router 

It forwards query request to the suitable instance manager based on cluster map information and also 
from outside the cluster. Also, it provides location transparency of a tenant's database. The job of router need 
to be balanced the load across the tenant’s replicas in round-robin pattern. 


Application 


Tenant 1 (multiple Tenant N (multiple users(s)) 


user(s)) tne | 
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Cluster Head 


Tenant Contig 
Data 


Instance Manager instance Manager Instance Manager 
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Caching database Caching database Caching database 
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Figure 2. A supple infrastructure for multi-tenancy over in-memory database 


If a replica of a tenant becomes unavailable in consequence on failure of a server [4, 5] requests need 
to be balanced amongst the remaining live replicas. The query results send back to the application through the 
router. 


3.1.3. Instance Manager 

The job of instance manger is to manage the distribution of requests across the tenant user. When 
instance manager receive a write request, it write to caching database [6] (if no space over main memory) and 
also forward the request to its successor node in a cluster. While, handling the database over no. of servers 
concurrent requests may cause performance issues and it effect on application execution. To resolve this 
problem we have experimented on oracle sharding architecture to support elastic scale. Request for the write 
operation need to be obstinately written on i node out of n nodes and then asynchronously replicated to the 
nodes i + | to n. Each tenant consists two consistent replicas and Individual instance manager is coupled up 
with a local oracle instance, which is shared amongst multiple tenants. Oracle instance support the approach 
of multitenancy [7] and in-memory. A local oracle instance needs to be paired with instance manger. 


3.2. Benchmark design 

We have used dedicated sample benchmarks for mixed workload processing that benchmark called 
HRSB-MT shown in Table 1. Our testing experiment is on oracle in-memory column database, which runs for 
mixed workload processing application. In column-oriented approach, database keep every attribute for in a 
separate column structure and is ideal for analytics, since it allows for speedy data retrieval when only a few 
columns are selected but the query accesses a huge portion of the data set. When DML operation (insert, update 
or delete) occurs on both methods then row-oriented format is extremely effective for processing DML as it 
manipulates an entire row or record in one go. A column approach is not so proficient as compared to row 
format at processing row-wise DML but for OLAP, larger chunk of data column-oriented gives simultaneous 
data execution. HRSB-MT model also opted dictionary-based compression techniques. 
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Table 1. HR schema benchmark-MT 


Table name Table size (MB) 
Region 951955 
Countries 220224 
Locations 332 
Departments 5171 

Jobs 1032567 
Employees 1956879 


3.3. Resource consumption of multiple homogeneous tenant 

So, by considering a framework which takes workloads of the tenant as input, their performance SLOs 
[8], [9] and the server hardware which is obtainable to the SaaS provider, and result into a cost-effective recipe 
which specifies utilization of hardware to deliver and how the tenants are scheduled on available hardware 
resource. Each tenants contain the same size and request rate on sever. Total no. of users is distributed 
uniformly among all tenants and the server is filled up only 15-20% of its main memory is used. The tenant 
size ts is divided by the resultant amount of memory. As a result depending on the chosen value for ts server 
may contain few or more tenants, so we vary ts from 20 to 198 MB (from 400,000 to 4,000,000 rows). Request 
per tenant is denoted by TR and it may increase until SLO violated [10], [11]. Figure 3 shows that when the 
number of tenants is increased by a factor of 10, throughput decreases by 10%. A SLO perspective [12] violates 
whether the server scan function is utilized by small number of large tenants or several small tenants. 


MB Scanned/ Second 


% “ 20 n % i) 0 rT) 


No. of Teoants on server 


Figure 3. Maximum throughput without violation the performance SLO 


4. STANDING TENANT PLACEMENT 
For standing tenant placement, we have considered following general data as input. 
A valid tenant assignment is performed using binary decision x € {0, 1} §*7*, where 


(y) 
‘! = £1, if tenant copy y is on sever i, otherwise 0} (1) 


s € {0,1}N (2) 


Where s=1 indicates that specific server i is active, otherwise server is inactive. 

Now, as performing tenant placement also needs to be checked that replica of tenant is allocated to a 
server once or not and no two copies of the same tenant. So, to check the specific condition we have applied 
some constraints. 


> x, a = 1 
ieN VtET,VVER (3) 
a <1 
gen VtET,ViEN (4) 
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The server in-memory capacity needs to fit on full amount size of all tenant on that server. 


Yo Vo Wex! <c. es, 


tel Meh vie N (5) 


One of the important key features of greedy heuristics is that they are computationally less rigorous 
than meta-heuristics. Greedy algorithms are loosely based on the well-known best-fit algorithm. It also delivers 
good results for the related bin-packing problem. Although the problem in a best fit algorithm consist constant 
approximation ratio over bin packing. So, when the tenants are small it inclined to bundle lots of tenants on a 
server. Best-fit algorithm is used for tenant placement, which finds the server with the least remaining resource 
that can accommodate each tenant, and in case such a server cannot be found, either relaxes the constraints 
gradually or use a new server. Starts with a random placement. It assumes a fixed number of tenant types and, 
on each server, it assigns tenants of the same type to the same database server instance with a fixed amount of 
main memory allocated [13]. 


4.1. Proposed multitenant placement (MTP) algorithm 

When tenant’s quantity is increasing then we need to apply tenant placement algorithm to allocate 
server resources [14], [15]. Parameters for MTP algorithm as shown in Table 2 are illustrate the tenant, server 
capacity, replica of tenant and other resource parameters. 


Table 2. MTP parameters 


Symbol Meaning 
TcNT Shows no. of tenants, Ti represent ith 
tenant 
Sc IS No. of servers (to show resource 
iz allocation) 
o: T>NT' Function returns Main memory 


requirement of a given tenant 
Cc Function returns Main memory capacity 
Oo. §-4IS* of ith server 


The purpose of mentioned algorithm which implemented on proposed architecture is to improve 
utilization of server to the set of tenants. Allocating proper resources over the tenants, we have deployed the 
tenant placement algorithm in Cluster head to improve server utilization. To fulfil tenant's service quality as 
its basis requirement, the performance testing use basic function swapping as a result it is considering minimum 
number of servers as and when it is required. On the base of meeting the requirements of service quality of the 
tenant, experimental test use best fit heuristic algorithms which is compared with the proposed MTP algorithm. 
In a resulting outcomes MTP requires less number of servers. 


Algorithm: MTP 


Cc 
Input: T Tenants, Server in-memory capacity %, Replica y 


Find binary value thru eq. (1) (0,1) 


ES Batok ae one tn}= sorted list of tenant in decreasing order with respect of size 
for server i in S = { 1,2,3} do 
2 
iy 
for each t; € T : 
2 
ey 
if * then 


x) 


locate other server j such that Bd 


call swap(t, i, j) 
else 
place t; on server 
end if 
end for 
call o(T[i]) 


Cc 
if (T[i]< °%) then 
S[jJ=S[j]-Tli] 
end if 
end for 
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5. EXPERIMENTAL SETUP AND RESULTS ANALYSIS 

The experiments were carried out on a cluster of three servers which is shown in Figure 2, each having 
16GB memory, VM(s), running centOS and oracle in-memory database. We produced up to 60 tenants. Each 
tenant runs with mix workloads in proportion to the generated query pattern. Concerning the sizes of the 
tenants, we measured the in-memory database with multitenancy settings existing in microsoft SQL azure [16], 
[17]. Figure 4 shows that number of tenants placed on each server (1.e. no of server = 2, 3 and 4) for resource 
allocation [16]. If there are 8 tenants labeled as A, B, C, D, E, F, G, H and for three server numbered as 1, 2 
and 3. If tenant B, C, D placed on server | then 1= {B, C, D} likewise for others tenants too. When the number 
of servers is not enough, both algorithm best fit and MTP uses different strategies. Figure 4 shows no. of tenants 
placed on each server numbered as 1, 2 and 3. In this paper we adopt the SLA penalty model [17], if queries 
arrived during server overload will fail to notice their SLA deadlines and the penalty need to be paid by service 
provider; and other queries will meet their SLA. Reason is using the load of a tenant will change very frequently 
for opting SLA model. SLA penalties occur mostly due to prolonged system overload instead of a temporary 
burst in arrival of query for a short period (example arrival during 10 millisecond). 


8 
6 @ Best Fit 
4 MTP 
2 
0 = = 
1 2 3 


Server ID 


No. of Tenant on Server 


Figure 4. Number of tenant on sever 


As it shown in Figure 5 shows that how query processed using two different approaches: Best fit 
greedy and MTP, in which best fit worked on hard disk based query processing while MTP processed query 
over in-memory database cluster. Cost of query processing through tenant is comparatively low in MTP than 
best fit greedy and also works effectively than best fit. We have also experimented scalability of tenant 
placement. Figure 6 shows running time of MTP which is for 50 tenants. Running time for best fit greedy is 
insignificant below 0.3 second even for 30 tenants, whereas MTP takes bit longer time than best fit greedy 
approach. 
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Figure 5. Effectiveness of tenant placement Figure 6. Scalability of tenant placement 
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6. CONCLUSION 

Multitenancy with in-memory database (opted in oracle) speeds up the processing and response time 
of data request. For in-memory database we have tested over different platform like SAP HANA, grid grain 
and oracle. In this paper we have proposed multitenancy architecture (supple) using in-memory database with 
proposed MTP algorithm. From the perspective of efficiency the paper shows proposed MTP algorithm in 
comparison with Best fit Greedy approach with database benchmark (HRSB-MT) over few tenants to improve 
the quality of tenant placement. While this paper focuses on supplement architecture for multitenant with in- 
memory database, in future will work on dynamic placement approach. 
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